Whiteline: delta/whiteline CD Series - delta.iso/document/hypertxt/ximgtool/ximgtool.ger

Text File | 1995-11-25 | 11KB | 247 lines

    Dokumentation zu XIMGTOOL und IMGCODEC-Sourcecode

            Stand: Apr 25 1995


1. Überblick
""""""""""""

Hiermit wird eine Erweiterung des IMG-Formates für Monochrom- und
Farbpalettenbilder vorgestellt. Das Ziel bestand darin, das bekannte
IMG-Pack- und Entpackverfahren so weit wie möglich zu verallgemei-
nern und damit die mögliche Packrate zu steigern, ohne völlig neue
Algorithmen einzuführen.

Das Ergebnis ist die Definition von 3 Stufen des IMG-Formates, be-
zeichnet als Level 1, 2 und 3. Level 1 ist dabei der 'Kompatibili-
täts'-Level, also mit dem bisherigen Verfahren identisch. Level 2
und 3 definieren naheliegende Erweiterungen, die so ausgelegt sind,
daβ ein entsprechender Decoder auch die niederen Level ohne Zusatz-
aufwand bearbeiten kann! Ein solcher Decoder wird im Sourcecode
mitgeliefert und ist so ausgelegt, daβ er auf flexible Weise in
Anwendungsprogramme eingebunden werden kann. Das Utility XIMGTOOL
demonstriert die Anwendung sowohl des Decoders als auch der beige-
fügten Encoder und soll als Hilfsmittel für die beliebige Konver-
tierung zwischen den Level dienen. Gleichzeitig mit dem hier ver-
öffentlichten Tool und den Sourcen wird eine neue 1STGUIDE-Version
herausgegeben, die bereits den Level-3-Decoder enthält und somit
zur praktischen Kontrolle der Verfahren benutzt werden kann.

Der Effekt der durch die Erweiterungen erreichten Verbesserungen
der Packrate ist unterschiedlich und hängt von der Art der Bilder
ab. Vor allem bei typischen Bildschirm-Snapshots von Desktop-Szenen
oder Linien- bzw. Objekt-Zeichnungen wurden erstaunliche Einspa-
rungen von durchschnittlich 15 %, manchmal um 30 %, erzielt.
Weniger Einsparungen ergeben sich bei Photomaterial, aber auch
dabei können immerhin einige KBytes Ersparnis bei durchschnittli-
chen Motiven erreicht werden.


2. Level-Definition
"""""""""""""""""""

Die Kennzeichnung des Levels einer IMG-Datei erfolgt durch Eintrag
der entsprechenden Nummer als 'IMG-Version' im IMG-Header. Dies ist
das erste Word in der Datei und somit mittels eines Hex-Dumps sehr
leicht zu erkennen.
Bisher stand dort der Wert 1. Dies wird nun als Level-1 interpre-
tiert. Bei einem Level-2 kodierten Image wird hier nun eine 2, bei
Level-3 eine 3 eingetragen. Dies soll hauptsächlich Informations-
zwecken dienen, denn der grundsätzlich empfohlene und mitgeliefer-
te Level-3-Decoder arbeitet unabhängig von diesem Wert!
Manche Programme testen den Versions-Wert ab und warnen den Anwen-
der, wenn dieser Wert gröβer als 1 ist. Das ist korrekt, denn wahr-
scheinlich kommen die Programme mit den hier definierten Erweite-
rungen noch nicht zurecht. Andere Programme (so auch vormalige
Versionen von 1STGUIDE) liefern 'Bildschirmmüll', wenn man mit
ihnen Level-2 oder Level-3 Images lädt.
Ein Programm, welches bisher auf Maximum 1 getestet hat, kann nach
Einbau des Level-3-Decoders einen Test auf Maximum 3 durchführen,
um die 'Gutartigkeit' zu erhalten.

Hier folgt nun eine kurze Übersicht über die Eigenschaften der ein-
zelnen Level (Details siehe Sourcecode):


Level-1:
--------
Kompatibilität, d.h. sollte von allen Programmen, die bisher schon
korrekt IMG-Dateien behandelt haben, verarbeitet werden können.
- Packmethoden auf Planes beschränkt, d.h. weder Plane- noch Line-
  Überschreitung innerhalb eines Packmodus zugelassen.
- vertical replication count (vrc): 1 bis 255 mal Wiederholung der
  aktuellen Zeile.
- pattern run: 1 bis 255 mal Wiederholung eines 'Musters'.
- solid run: 1 bis 127 mal Wiederholung eines 0/0xFF-Bytes.
- byte string: Übernahme der nächsten 1 bis 255 Bytes.

Level-2:
--------
- Die Packmethoden müssen nicht mehr auf einzelne Planes einer Zeile
  beschränkt sein. Allerdings darf die Zeilengrenze weiterhin nicht
  überschritten werden.
- Bei vertical replication count (vrc) und byte string wird ein
  0-Byte als 256 interpretiert.
- Einführung des 'extended vertical run mode': Kodierung der
  Wiederholung einer Bytefolge in Bezug auf die vorherige Zeile
  durch erweiterte Interpretation des Zusatzbytes 0xFF beim
  'vollen' vrc. Dies kann als Verallgemeinerung des 'full vrc'
  auf sich wiederholende Teilfolgen einer Zeile aufgefaβt werden.

Level-3:
--------
- Hier fällt auch die Beschränkung der Packmodi auf Zeilengrenzen!
  Dank der benutzten ('objektorientierten') Datenstrukturen wird
  jedoch beim Dekodieren weiterhin nur ein einziger Zeilenpuffer
  benötigt!
- Alle genannten Level-2 Erweiterungen gelten hier natürlich auch.


Die Wirkung der einzelnen Erweiterungen auf die Packrate ist, wie
bereits erwähnt, unterschiedlich. Besonders der 'extended vertical
run mode' ab Level-2 wirkt bei manchen Inhalten angesichts der Ein-
fachheit Wunder, bei anderen bringt er kaum etwas.
Die wegfallende Planegrenze bei Level-2 kann natürlich umso mehr
einsparen, je mehr Planes, also Farben, vorhanden sind. Bei Mono-
chrombildern hat dies keine Auswirkung, hierbei kommen also die
Einsparungen vor allem durch den extended vrc zustande.
Der Fall der Zeilengrenze bei Level-3 bewirkt gegenüber Level-2 mehr
oder weniger geringfügige Einsparungen - im Durchschnitt etwa 1 Byte
pro Zeile, manchmal weniger, manchmal auch deutlich mehr. Probieren
Sie es einfach aus und sammeln Sie damit Erfahrungen!


3. XIMGTOOL.TTP
"""""""""""""""

Hiermit hat man ein Hilfsmittel zur Hand, um ausgiebig die Möglich-
keiten der verschiedenen Verfahren auszutesten und auszunutzen.

Aufruf:  ximgtool [Optionen] Input [Output]

Optionen:


-lN:
----
Benutze Level-N-Encoder, N=1..3. Wird diese Option nicht angegeben,
so wird der Level des Inputs verwendet (eingeschränkt auf 1..3).
Wenn Sie also etwa vorhandene IMG-Dateien (Level-1) maximal packen
wollen, so müssen Sie -l3 angeben. Die so erzeugten Files können
natürlich nur von 'fähigen' (Level-3) Decodern ausgepackt und so-
mit kontrolliert werden, vorerst ist das die aktuelle 1STGUIDE-
Version. Andere Programme werden hoffentlich schnell folgen.
Sie können dies aber trotzdem etwa zur Archivierung der Bilder
verwenden: Mit XIMGTOOL können Sie notfalls die Files wieder in
den kompatiblen Level-1 verwandeln und dann mit anderen Programmen
verarbeiten. Geben Sie dazu -l1 an. XIMGTOOL selbst benutzt grund-
sätzlich den universellen Level-3-Decoder.
Die verwendeten und im Sourcecode vorliegenden Encoder sind bereits
das Ergebnis einer ausgedehnten Optimierungsphase. So erzeugt etwa
selbst der kompatible Level-1-Encoder meist geringfügig kleinere
Files als die bisher effektivsten mir bekannten Programme, nur in
sehr seltenen Fällen gibt es kleine Verluste. Das Optimum bei den
Encodern ist also noch nicht erreicht, hier sind sicher in Zukunft
noch Verbesserungen möglich, während es am Decoder keine wesentli-
chen Änderungen mehr geben kann.

-pN:
----
Erzeuge Output mit pattern run N, N=1..2. Standardmäβig wird der
pattern run des Inputs verwendet (eingeschränkt auf 1..2).
Der pattern run ist eine globale IMG-Variable und läβt sich daher
leider nicht ohne weiteres in einem Pass optimieren. Manche Bilder
erreichen höhere Packraten mit 1, andere mit 2. Da hilft nur Aus-
probieren!

-i:
---
Identifiziere den Input, keine Kodierung.

-m:
---
Mehrfach-Modus (Batch). Als Input kann dann ein Muster mit Standard-
Wildcards angegeben werden. ACHTUNG für GEMINI-Anwender: In der
Console muβ man die Wildcard-Angabe 'quoten', um die automatische
Expansion durch die Shell zu verhindern! Als Output ist ggf. ein
Ziel-Ordner anzugeben.


Input:  Quelldatei (Muster bei -m).

Output: Zieldatei (Ordner bei -m).

Nach Bearbeitung wird die Anzahl der Input- und Output-Bytes sowie
die Differenz angezeigt. Letztere ist in der Regel positiv (Einspa-
rung) bei Konvertierung zu einem höheren Level, negativ bei Konver-
tierung in einen niederen Level.
Hinweis: Auch ohne Angabe eines 'Output' wird eine vollständige
Kodierung (dann nur im Speicher) durchgeführt und es werden die ent-
sprechenden Werte angezeigt, was für Testzwecke nützlich sein kann.
Bemerkung: Ein erweiterter XIMG-Header wird von XIMGTOOL in keiner
Weise ausgewertet, er wird direkt in das Outputfile übernommen.


4. IMGCODEC-Sourcen
"""""""""""""""""""

Um eine möglichst schnelle und einfache Verbreitung und Nutzung zu
erreichen, werden vollständige Sourcen für Kodierung und Dekodierung
verfügbar gemacht. Detail-Hinweise entnehme man den eingestreuten
Kommentaren.
Während es, wie bereits erwähnt, am Decoder eigentlich nichts mehr
wesentlich zu verändern gibt, sind an den Encodern wahrscheinlich
noch Optimierungen möglich, wenngleich hier bereits einiger Aufwand
investiert wurde. Es werden alle jeweils verfügbaren Packmodi
genutzt und eine eigene vrc-Behandlung durchgeführt, unabhängig von
den im Inputfile bereits vorhandenen vrc's. Es sollte also für ein
und denselben Bildinhalt immer das gleiche Resultat herauskommen,
unabhängig von der Kodierung des Inputfiles.
Wer einen Beitrag zur Verbesserung der Encoder leisten kann, sei
hiermit herzlichst dazu eingeladen, dies kundzutun und einflieβen
zu lassen. Man beachte aber: Es ist sehr leicht, einen Encoder zu
basteln, der spezielle Inhalte besser packt, dafür aber bei anderen
Daten deutliche Verluste bringt. Es kommt also immer auf das Testma-
terial an, dieses sollte möglichst umfangreich und anwendungstypisch
sein. Erst wenn man eine Routine gefunden hat, die bei typischen
Bildern deutliche Einsparungen bringt und höchstens im Ausnahmefall
geringfügig verliert, kann man dies allgemein ins Auge fassen.

Neben den reinen Codec-Sourcen gibt es noch Anwendungsbeispiele
für MFDB-Input und -Output, die als Vorlage für entsprechende
Applikationen dienen können.


5. Ausblick
"""""""""""

In Vorbereitung ist derzeit die Erweiterung des IMG-Formates auf
True-Color-Unterstützung (allgemeiner Direct-Color, es wird auch
High-Color-Modi umfassen). Da die Auswertung und Darstellung
dieser Variante jedoch aufwendiger und umfangreicher ausfallen
wird, sollte zunächst die hier vorliegende Level-Spezifikation
aufgrund des allgemein geäuβerten Interesses unverzüglich ver-
öffentlicht werden. Die TC-Erweiterung wird auch von der Level-
Spezifikation unabhängig sein, ja es kann sogar garantiert werden,
daβ die jetzigen Routinen mit der künftigen Erweiterung ohne
Änderung weiterverwendet werden können, da sich diese Erweiterung
nur auf die Festlegung eines entsprechend erweiterten IMG-Headers
zur Interpretation der Pixeldaten beziehen wird. Die Pixeldaten
selbst werden nach dem gleichen Schema behandelt.
Das XIMGTOOL.TTP wird grundsätzlich auch für die TC-Files benutzt
werden können, da es unabhängig von erweiterten Header-Informationen
und der Interpretation der Pixeldaten arbeitet.


6. Bezugsadresse
""""""""""""""""

Sachdienliche Hinweise sind jederzeit willkommen und werden dankend
entgegengenommen. Eine vertrauliche Behandlung ist ausgeschlos-
sen ;-). Bitte wenden an:

    Guido Vollbeding
    Turmstraβe 61
    [D-]06110 Halle (Saale)
    [Deutschland]